This PR is still in draft as with this change the filter and multiFilter does not work anymore as we don't have the whole object in the query anymore.. therefore we should think how we can fix that.

As expected these tests are failing:

Error:  Failures: 
Error:    TestServiceTest.labelValuesFilterMultiSelectBoolean:582 1 expectation failed.
Expected status code <200> but was <500>.

Error:    TestServiceTest.labelValuesFilterMultiSelectNumber:555 1 expectation failed.
Expected status code <200> but was <500>.

Error:    TestServiceTest.labelValuesFilterMultiSelectStrings:528 1 expectation failed.
Expected status code <200> but was <500>.

With the latest 2 commits I did:

• Moved the labelValues logic into a separated service - I think this is a great readability and maintainability improvement
• Fixed the filter and multiFilter when the provided filter is a JSON object (which showed a great improvement wrt the current master branch when using a filter - will share some results later)
• Applied the same improvement on RunService.labelValues call

There are still some TODOs:

• Fix the logic when the provided filter is a JSON path - @johnaohara @willr3 do we want to keep supporting this use case? If not I won't spend time on this - the only solution I see is to decompose the jsonpath and extracting the root.
• Fix the ordering by jsonpath - this is not working anymore as we have not the aggregated json in the query, @johnaohara @willr3 is this something we want to keep supporting? with this new implementation I don't even think this is still possible as this kind of ordering can be done in Java code once we aggregated JSON node - therefore we cannot use the psql jsonpath 🫤 As agreed this won't be supported any longer, just start/stop ordering other than the default by runId (or datasetId for labelValues for specific run)

@willr3 @johnaohara I am not fully satisified about the dirty trick I had to do in order to decompose the jsonpath for the jsonpath filter but it looks working.

I did some other performance comparions between current master branch and this PR, I attached the main important ones here 👉 https://issues.redhat.com/browse/MPL-455.

I am still a bit surprised about the x10 improvement in the case of filter obj (I'd like to investigate a bit more to ensure the response is actually the same - it was in my local env).

Anyway, I think this PR is ready for review and it comes with good improvements IMO but happy to get any feedback!

[edit] I kept different commits to highlight the different changes, I will squash them before merging if no other changes are required

@willr3 do you want to review this PR, looks good to me, but would be good to get a 2nd opinion as it is a big change to labelvalues

@willr3 do you want to review this PR, looks good to me, but would be good to get a 2nd opinion as it is a big change to labelvalues

taking a look

I rebased the PR and now some tests are failing, checking..

Fixed now!

@lampajr thanks for sorting the api issue, please squash commits and I will merge

@lampajr thanks for sorting the api issue, please squash commits and I will merge

Here we go, commits squashed @johnaohara 🚀